COMMENT ⊗   VALID 00008 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Things to do for new version on 11:
C00004 00003	Stuff about FREE:
C00010 00004	Things to do:
C00013 00005	Bugs
C00017 00006	Things to watch out for:
C00018 00007	General notes
C00023 00008	Files on the UDP (ROBOT3):
C00031 ENDMK
C⊗;
Things to do for new version on 11:

FREE still needs to be fixed up for flushVar (commented out for now).
(See next page.)

Look at ALL the modules and make sure that Ron didn't put in calls to 
   routines that are higher up in the calling heirarchy.

Should Edit routines be able to call routines from Interp even though they're
    at a lower level?

Change maxlines to 28; maxPPlines to 18 or so; listinglength to 2000 (or less?)
   then recompile all the stuff.

Combine emain5 with one of the other modules; it only has a dozen lines in it.

Might want to try this:  make a dummy module for each of the 5 header files
and make sure the last variable lands in the right place.
Also, better check the epar3i modules to makesure none of them have own hdr.

Make it use incore overlays.  This is only partially done now.
When I did it, it died at these addresses:
	062326
	065612
	065706
	065714 (most common)
	065734 (also common)

Stuff about FREE:

Q: What was it doing before?  Did I comment out the call to flushVar before,
   or is this whole thing new?
A: I don't remember. I believe the call to flushvar is new, i.e. a bug fix.

∂01-Apr-83  1349	ARG  	flushing flushvar in free    
 ∂31-Mar-83  1245	RV  	al change 
Hey Ron: You added a call to flushVar in FREE (in freeStatement).
What would happen if I commented out the call to it?  Anything real bad?

Rick - Well if you commented those calls to flushvar out, basically several
	records would not be deallocated that should be, which wouldn't be
	all that catastrophic. However maybe you could add the following
	abbreviated version of flushvar to free? Also below are all of the
	routines in interp that flushvar calls directly or indirectly.
								Ron

 procedure flushVar(oldvar: varidefp);
  var v,vp,vo: varidefp; j: integer; pold: pdbp;
  begin
  with oldvar↑ do
   begin				(* flush old unused variable *)
   with eCurInt↑.env↑ do
    if procp then j := proc↑.level else j := block↑.level;
   pold := curInt;
   curInt := eCurInt;		(* so we use right process to access var *)
   if level <= j then
     killVar(getEntry(level, offset));	(* active block flush its value *)
   curInt := pold;			(* restore current process *)
   vtype := freevartype;
   name := nil;
   end;
  end;

 procedure killVar(e: enventryp);
  var pp: pdbp; cp: cmoncbp;
  begin
  with e↑ do
   if etype = eventtype then
     begin
     pp := evt↑.waitlist;
     while pp <> nil do
      begin pp↑.status := nullqueue; pp := pp↑.next end;
     freeEvent(evt);
     end
    else if etype = cmontype then
     repeat
      if c↑.cmon↑.oncond↑.ntype = forcenode then freeEvent(c↑.evt);
      freePdb(c↑.pdb);		(* now it's ok to flush its pdb *)
      cp := c↑.oldcmon;		(* did we have several copies active? *)
      relCmoncb(c);		(* and also free up its cmoncb *)
      c := cp;
     until cp = nil;
  relEentry(e);
  e := nil;
  end;

 function envlookup (offset: integer; envhdr: envheaderp): enventryp;
  var i,j,k: integer; env: environp;
  begin
  i := offset div 10;			(* which environment block *)
  j := offset mod 10;			(* entry in environment block *)
  if i < 5 then env := envhdr↑.env[i]	(* use direct look-up *)
    else begin				(* run through linked list *)
	 env := envhdr↑.env[4];
	 for k := 5 to i do env := env↑.next;
	 end;
  envlookup := env↑.vals[j];
  end;

 function getELev(hdr: envheaderp): integer;
  begin
  if hdr = sysEnv then getELev := 0
   else if hdr↑.procp then getELev := hdr↑.proc↑.level
   else getELev := hdr↑.block↑.level;
  end;

 function getEntry (level, offset: byte): enventryp; 
  var hdr: envheaderp;
  begin
  if level = 0 then hdr := sysEnv  (* level zero is predefined system variables *)
   else
    begin
    hdr := curInt↑.env;		(* look up the env entry given level-offset *)
    while level < getELev(hdr) do hdr := hdr↑.parent;	(* move up a level *)
    if level <> getELev(hdr) then	(* yow!!! no environment exists!!! *)
      begin
      pp20L('Attempt to access no',20); pp20('n-existent environme',20);
      pp20('nt - good luck!     ',16); ppLine;
      end;
    end;
  getEntry := envlookup(offset,hdr);
  end;

Things to do:

It looks like, with full memory-resident overlaying, we have about
14000 bytes of memory left.  Use it sparingly!

    Sometime soon, combine some of the overlays, like arithn, paux1&2, etc.

    When receiving a ↑C - should signal arm code with (some event flag - later)
    a message.  Better put this in the main loop in IMAIN - is there room?

    Put more debug stuff in (↑Y).

    During initArms - should make cursor point to where next char typed will
    be.  Is there an easy way to do this?  Also make it look a little better.
    Maybe set ppSize to 6 or so.  Also, put in ppOutNow's after the prompt
    char is typed.

    When eProcParse is called, make sure it doesn't overflow the stack
    with its local array.


----------  	How to improve it 	----------------------------------------

    Try and find some way to increase the size of the heap.  Maybe have
    another task running that just stores stuff??

    Maybe have one module in a resident overlay that just stores Listing array.

----------	Other stuff		----------------------------------------

    Does it increase the size of a module to include external references that
    are not actually used?  Test this out.  There's a difference between
    unused routines that need to call an overlay and those for which an overlay
    call already exists.

    Possibly remove alloc.pas & replace with standard new & dispose.
    Make a little test program to see if dispose actually works.

    Call Chris Moe about latest version of Pascal-1.  The latest version OSMI
    supplies is 1.2K; we have 1.2F.  They confirmed that 2.0 cannot deal with AL.
    (we're site # 1-665).

Bugs

⊗ If you type in this program
	begin
	scalar i;
	for i:=1 til 3 do begin
	  move garm to garm-4*zhat;
	  move garm to garm+4*zhat;
	  end;
	end;
and run it, then stop it with control-C while it's doing a move,
it'll say "No processes currently active" and stop, pointing the cursor
to line 1; saying "@" does nothing.  Saying !P makes it go into a loop
(which you can stop with ↑C).


⊗ Fix the ↑S problem.  Use STEST.AL to test it.
May have to do this by trial/error since stest.pas doesn't seem to do it!
You might put in stuff to look for the ↑S and stop output until ↑Q is rec'd;
where to do this?  -- in disp.mac, in the calling routines?  Have a character
ast that checks?  Maybe make it wait for a bit (one tick?) after it does
inserts and deletes. Shouldn't be too hard.. may need to make the amt of
time depend on how many lines - e.g. 16 ms = 1 tick per line?


⊗ Running this program
	begin
	move garm to garm-7*zhat
	  with duration=7
	  on |force(zhat)| >= 20*oz do 
	    begin
	    stop garm
	    print("Got it",crlf);
	    end;
	end;
and pushing on the arm as it goes down (to signal the force monitor)
not only does not trigger the force monitor, but when the motion completes,
it dies (ref thru nil ptr) @ PC=162164.


⊗ Sometimes I see "old line wasn't freed"; could this be the potential bug
in PP:
    Look at pp.2/5p/25l - should we call relLine in here somewhere?
that I saw before?


⊗ The following is a bug:
Suppose you're entering a program into the editor:

	begin
	end;

	↓

	begin
	scalar procedure sum(value scalar n);
	  begin
	  end;
	end;


If you now try to insert the declaration "scalar i,j;" in front of
the procedure declaration, it says "can't have a declaration here".
If, on the other hand, you first put in the scalar decl and then,
following that, put the proc decl, it doesn't complain.


⊗ This little program doesn't get read in right - barfs at the "trans t1,..."
line.  Inserting the same line into the program works, though.

	begin
	trans f;
	frame f1,f2;
	frame f3,f4;
	trans t1,t2,t3;		{dies here}
	scalar i,j,k;
	print("Hi there",crlf);
	end;


Things to watch out for:

⊗ Watch out when EDIT calls FlushSomething - need to call Edit back in.

⊗ When EDIT calls FlushVar (defined edit/17p)
  it creates a lot of problems!  Check carefully.

General notes

To fix work file problem during TKB:
	REA TKB 10 DK1:

The total size of the AL system is 342764 (decimal bytes)
  This is as of about July 15, 1982

Sizes of records (as of March 24, 1983) (unchanged since last version)
  Event size is      6 bytes.
  Enventry size is   6 bytes.
  Ident size is      8 bytes.
  Token  size is     8 bytes.
  Resword  size is   8 bytes.
  String size is    12 bytes.
  Node size is      12 bytes.
  Cmoncb size is    12 bytes.
  Vector size is    14 bytes.
  Varidef size is   14 bytes.
  Frame size is     16 bytes.
  Envheader size is 16 bytes.
  Stmnt size is     22 bytes.
  Environment size: 22 bytes.
  Pdb  size is      28 bytes.
  Trans size is     50 bytes.

Cursorp size is	   8 bytes.

Files on the UDP (ROBOT3):

[AL0,RV]	Contains a snapshot of AL source files May 28, 1982, before
		  I changed anything (from Ron's [pas,arg]).

[AL1,RV] 	A snapshot of the .PAS files in which I changed ↑x to xp.

[AL2,RV]	Contains a snapshot of the .PAS files taken on June 9, 1982.
		  These are to be SRCCOM'd to later versions of the .PAS files
		  on [al,he] which Ron may change to correct bugs.
		  The version running on the 11 is made from exactly the source
		  code found in [al2,rv].  Compare these files on [al2,rv] to
		  the ones in [al,he], make the appropriate changes to the
		  .2 files, and (important) copy the new versions of the .pas
		  files on [al,he] to [al2,rv].

[AL3,RV]	All the .11 files from June 29, 1982.  This is the initial
		  editor-less version which ran on the 11 without the arm code
		  interface.

[AL4,RV]	Contains the working version, without arm code communication,
		  of AL with Editor.  Also some misc stuff.

[AL5,RV]	This is the initial version of AL with arm code communication.
		  No editor..

[AL6,RV]	This is the first working version of EAL with arm code
		  communication.  There may be compile errors in the code.
		  In fact there are!

[AL7,RV]	The last working version of EAL, version 1 Pascal.
		  This is almost identical to [al6,rv] but I made a copy
		  just to be safe (no bugs, anyway).  A duplicate copy
		  is on ROBOT4 for extra safety.
		  Remember that this is the one that Ron had changed some
		  of the constants in ALHDR for.

[AL8,RV]	The first working version-2 Pascal AL, version 2.A.
		  Has full resident overlays and TKB-combined overlays.
		  No modules have been physically combined.
		  Has a few bugs but otherwise seems to work.

[EAL,HE]	Backed up copies of all the files on [eal,he] that made
		  up the version of AL on the 11 as above.